Okta を使って WorkSpaces の SAML 統合をやってみた

SAML 統合を行っても、WorkSpaces へのログイン時にパスワードの入力は必要です。

#Amazon WorkSpaces

#SAML

#Okta

#AWS

まさを

2023.08.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさま Xin chao !

本ブログを執筆している時点ですでにかなりの時間が経過してしまっているのですが、2022 年 11 月に Amazon WorkSpaces で SAML 2.0 統合の一般提供が開始されたことが発表されています。

WorkSpaces で SAML 2.0 統合を使うと、WorkSpaces の利用者視点で WorkSpaces へのログインプロセスがどのように変わるのか？ SAML 2.0 についてはあまり詳しくないけれど試してみたい！ということで、実際に環境を構築して試してみました。

既存の WorkSpaces 環境に SAML 2.0 統合を設定してみる

AWS が公開しているホワイトペーパー「Amazon WorkSpaces SAML 認証実装ガイド (Amazon WorkSpaces SAML Authentication Implementation Guide (Last updated November 18, 2022))」をもとに試してみます。ホワイトペーパーは、以下のリンクから入手可能です。本ブログ執筆時点では、日本語版は未提供のようです。

構成図

今回 SAML 統合を実装するのは、以下のような環境です。

前提

以下の環境を構築・設定済みの状態から始めます。なお、AWS リソースはバージニア北部リージョンに作成しています。東京リージョンに作成していない理由は、バージニア北部リージョンの方が AWS 利用料金が概ね安価だからです (実際に環境を構築する際には、利用料金以外のことも考慮の上で使用するリージョンをご選択ください)。

Active Directory
- 今回は Windows Server 2019 を選択
- Active Directory ドメインコントローラー on EC2 (以降 AD on EC2) で構築
- Active Directory ドメイン名は oktasso.test (NetBIOS 名は OKTASSO)
- WorkSpaces のユーザーとして、以下のユーザーを作成
  - user01
AWS Directory Service
- WorkSpaces で使用する Directory Service は Active Directory Connector (以降 AD Connector)
Amazon WorkSpaces
- 動作確認用として user01 用の WorkSpace をデプロイ
Okta
- 検証環境用に Okta Starter Developer Edition を使用
- 設定を行うためスーパー管理者権限を持った Okta アカウントを取得済みで Okta Admin Console へのサインインも確認済み
Okta Active Directory agent
- Active Directory -> Okta の統合は設定済みで、Active Directory ユーザー・グループを Okta にインポート済み
接続用 PC
- Google Chrome ＋検証時点での最新版 WorkSpaces クライアントアプリケーション (バージョン 5.12.0) がインストール済みの Windows 11
- [email protected] で Okta へのサインインを確認済み

Okta の Active Directory 統合をこれから設定する場合は、以下のブログが参考になるかもしれません。

SAML 2.0 統合の設定の流れ

以下の 5 つのステップで設定していきます。

SAML 2.0 メタデータマニフェストの生成 (Okta Admin Console での設定)
SAML 2.0 Identity provider の作成 (AWS マネジメントコンソールでの設定)
SAML 2.0 フェデレーション用 IAM ロールおよび IAM ポリシーの作成 (AWS マネジメントコンソールでの設定)
Okta の設定 (Okta Admin Console での設定)
WorkSpaces ディレクトリでの SAML 2.0 統合の有効化 (AWS マネジメントコンソールでの設定)

1. SAML 2.0 メタデータマニフェストの生成 (Okta Admin Console での設定)

まずは Okta Admin console での操作になります。

Okta Admin Console にスーパー管理者権限を持ったユーザーでサインインします。

ナビゲーションペインで、[Applications] - [Applications] をクリックし、[Create App Integration] をクリックします。

"SAML 2.0" を選択し、[Next] をクリックします。

[(1) General Settings] タブで以下のように設定し、[Next] をクリックします。

App name : (WorkSpaces 利用者から見て、WorkSpaces SAML 統合アプリケーションであることが分かるような名前を入力します)
App logo (optional) : (必要に応じて WorkSpaces SAML 統合アプリケーションであることが視覚的に判別しやすくなるような画像ファイルをアップロードします) (註 : 使用可能な画像最小サイズは 420 x 120 ピクセルです)

[(2) Configure SAML] タブで以下のように設定し、[Next] をクリックします。

Single sign-on URL : https://signin.aws.amazon.com/saml
Audience URI (SP Entity ID) : urn:amazon:webservices

[(3) Feedback] タブで以下のように選択し、[Finish] をクリックします。

Are you a customer or partner? : I'm an Okta customer adding an internal app (これを選択すると、任意の追加フィードバック項目が表示されますが、必要に応じてご回答ください)

[Sign On] タブで、"SAML Setup" 欄にある [View SAML setup instructions] をクリックします。

"How to Configure SAML 2.0 for WorkSpaces SAML Application" の画面で、最下部の "Optional" に表示されている XML テキストをメモ帳などのテキストエディターにコピーし、テキストファイルとして保存します。この XML テキストファイルは、[2. SAML 2.0 Identity provider の作成] の手順で使用します。また、XML テキストは複数行になっているので、コピー＆貼り付け漏れがないようにご注意ください (今回試した時は計 17 行でした)。

戻るボタン等はないようなので、この画面が別タブで開かれている場合にはタブをそのまま閉じます。

2. SAML 2.0 Identity provider の作成 (AWS マネジメントコンソールでの設定)

次は、AWS マネジメントコンソールでの操作になります。

[IAM] - [ID プロバイダ] に移動し、[プロバイダを追加] をクリックします。

"ID プロバイダの追加" 画面で以下のように設定し、[プロバイダを追加] をクリックします。

プロバイダのタイプ : SAML
プロバイダ名 : (このプロバイダを識別するための名前を入力します)
メタデータドキュメント : ([1. SAML 2.0 メタデータマニフェストの生成] の最後の手順で保存した XML テキストファイルを選択します)

画面上部の [プロバイダを表示] をクリックします。

"概要" 欄にある ID プロバイダの "ARN" をコピーしておきます。 "ARN" は、この後行う [4. Okta の設定] の手順で使用します。さらに、"メタデータドキュメント" 欄にある "SSO サービスの場所" をコピーしておきます。 "SSO サービスの場所" は、この後行う [5. WorkSpaces Directory での SAML 2.0 統合の有効化] の手順で使用します。

3. SAML 2.0 フェデレーション用 IAM ロールおよび IAM ポリシーの作成 (AWS マネジメントコンソールでの設定)

引き続き、AWS マネジメントコンソールでの操作になります。

[IAM] - [ロール] に移動し、[ロールを作成] をクリックします。

”信頼されたエンティティを選択" 画面で以下のように設定し、[次へ] をクリックします。

信頼されたエンティティタイプ : SAML 2.0 フェデレーション
SAML 2.0 ベースのプロバイダー : ([2. SAML 2.0 Identity provider の作成] の手順で作成した ID プロバイダを選択)
属性 : SAML:sub_type
値 : persistent

"許可を追加" 画面では何も追加せずに [次へ] をクリックします。

"名前、確認、および作成" 画面で以下のように設定し [ロールを作成] をクリックします。

ロール名 : (この IAM ロールを識別するための名前を入力)

画面上部の [ロールを表示] をクリック、または、ロールの一覧から作成したロールを検索しクリックします。

[信頼関係] タブを表示し、[信頼ポリシーを編集] をクリックします。

"STS のアクションを追加" 欄に "tagsession" を入力すると、表示されているステートメントがフィルタリングされるので、"TagSession" を選択します。これにより、信頼ポリシーに "sts:TagSession" アクションが追加されたことを確認したうえで、[ポリシーを更新] をクリックします。

[許可] タブを表示し、[許可を追加] - [インラインポリシーを作成] をクリックします。

"アクセス許可を指定" 画面で、［JSON］をクリックします。

ポリシーを以下の内容に置き換え、さらに環境に合わせて一部文字列を書き換えたうえで [次へ] をクリックします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "workspaces:Stream",
            "Resource": "arn:aws:workspaces:REGION-CODE:ACCOUNT-IDWITHOUT-HYPHENS:directory/DIRECTORY-ID",
            "Condition": {
                "StringEquals": {
                    "workspaces:userId": "${saml:sub}"
                }
            }
        }
    ]
}

REGION-CODE ：WorkSpaces 用の Directory Service が存在するリージョンコード
ACCOUNT-IDWITHOUT-HYPHENS : お使いの AWS アカウント番号 (ハイフンなしで)
DIRECTORY-ID : WorkSpaces 用の Directory Service のディレクトリ ID (d-xxxxxxxxxx)

リージョンコードについては、以下のドキュメントをご参照ください。

"確認して作成" 画面で、以下を設定して [ポリシーの作成] をクリックします。

ポリシー名 : (このインラインポリシーを識別するための名前を入力)

"概要" 欄にある IAM ロールの "ARN" をコピーしておきます。 "ARN" は、この後行う [4. Okta の設定] の手順で使用します。

4. Okta の設定 (Okta Admin Console での設定)

再び Okta Admin Console での操作になります。

Okta Admin Console にスーパー管理者権限を持ったユーザーでログインします。

ナビゲーションペインで、[Applications] - [Applications] をクリックします。

[1. SAML 2.0 メタデータマニフェストの生成] の手順で作成した WorkSpaces SAML アプリケーションをクリックします。

[General] タブの "SAML Settings" 欄にある [Edit] をクリックします。

[(1) General Settings] タブでは、何も変更せずに [Next] をクリックします。

[(2) Configure SAML] タブで、環境に合わせて一部文字列を書き換えたうえで、"SAML Settings" を以下のように設定します。設定には続きがあるため、まだ [Next] はクリックしないでください。

Default RelayState : https://RELAY-STATE-URL/sso-idp?registrationCode=DIRECTORY-REGISTRATION-CODE
- RELAY-STATE-URL ・・・ WorkSpaces が存在しているリージョンのリレーステートのエンドポイント
- DIRECTORY-REGISTRATION-CODE ・・・ WorkSpaces ディレクトリの登録コード (例. ABcde+FGHIJK)
Name ID format : Persistent
Application username : AD SAM account name

リレーステートのエンドポイントについては、以下のドキュメントをご参照ください。

ステップ 6: フェデレーションのリレーステートを設定する - SAML 2.0 の設定

引き続き [(2) Configure SAML] タブで、環境に合わせて一部文字列を書き換えたうえで、"Attribute Statements (optional)" を以下のように設定し、[Next] をクリックします。既定の状態では、1 行しか入力欄が存在しないため、[Add Another] を 3 回クリックして入力欄を計 4 行に増やします。

(1行目)
- Name : https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email
- Name Format : 指定なし (Unspecified)
- Value : user.email
(2 行目)
- Name : https://aws.amazon.com/SAML/Attributes/RoleSessionName
- Name Format : URI 参照 (URI Reference)
- Value : userName
(3 行目)
- Name : https://aws.amazon.com/SAML/Attributes/Role
- Name Format : URI 参照 (URI Reference)
- Value : ROLE-ARN,IDP-ARN
  - ROLE-ARN ・・・ [3. SAML 2.0 フェデレーション用 IAM ロールおよび IAM ポリシーの作成] の手順で作成・コピーした IAM ロールの ARN
  - IDP-ARN ・・・ [2. SAML 2.0 Identity provider の作成] の手順で作成・コピーした ID プロバイダの ARN
(4 行目)
- Name : https://aws.amazon.com/SAML/Attributes/SessionDuration
- Name Format : 基本 (Basic)
- Value : 900
  - Value ・・・この値は、SAML 認証がユーザーセッションに対して有効である秒数を示し、最小 900 ～最大 43,200 を設定可能です (設定を省略した場合のデフォルト値は 3,600 秒＝ 60 分になります)

[(3) Feedback] タブでは、何も変更せずに [Finish] をクリックします。

[Assignments] タブを表示し、WorkSpaces SAML アプリケーションを割り当てるユーザー or グループを指定するため、[Assign] をクリックし、[Assign to People] または [Assign to Groups] をクリックします (今回は user01 のみ割り当てるため [Assign to People] を選択しています)。

これは、[Assign to People] をクリックした場合の画面になります。 [Assign (YOUR APPLICATION NAME) to People] ウィンドウで、WorkSpaces SAML アプリケーションを割り当てるユーザー (user01) の、右側にある "Assgin" をクリックします。

確認が求められるので、WorkSpaces SAML アプリケーションを割り当てるユーザーが正しいことを確認したうえで [Save and Go Back] をクリックします。複数ユーザーに対してアサインする場合は、操作を繰り返します。

対象のユーザーが "Assigned" に変更されたことを確認し、[Done] をクリックします。

[Assignments] タブに、WorkSpaces SAML アプリケーションが割り当てられたユーザーが表示されました。

5. WorkSpaces Directory での SAML 2.0 統合の有効化 (AWS マネジメントコンソールでの設定)

最後は再び AWS マネジメントコンソールでの操作になります。

[WorkSpaces] - [ディレクトリ] に移動し、WorkSpaces で使用され、SAML 統合を有効化するディレクトリのディレクトリ ID をクリックします。

[認証] 欄の [認証を編集] または [編集] をクリックします。

[認証を編集] 画面で、"SAML 2.0 アイデンティティプロバイダー" 欄の [SAML 2.0 アイデンティティプロバイダーの編集] をクリックします。

[編集: SAML 2.0] 画面で、以下のように設定し [保存] をクリックします。

SAML 2.0 認証の有効化 : 有効
ユーザーアクセス URL : ([2. SAML 2.0 Identity provider の作成] の手順で作成・コピーした ID プロバイダの "SSO サービスの場所" を貼り付け)
IdP ディープリンクパラメータ名 - オプション : RelayState

動作確認してみる

SAML 統合を使用する環境では、WorkSpaces へのログオンは、Okta から行う方法と、WorkSpaces クライアントアプリケーションから行う方法の 2 種類があるので、両方の方法を試してみます。

Okta からログイン

まずは、Okta から WorkSpaces のログインプロセスを開始してみます。

Okta に [email protected] でサインインします。

My Apps に登録されている WorkSpaces SAML アプリケーションをクリックします。

Web ブラウザから「workspaces を開きますか？」と訊かれるので、[workspaces を開く] をクリックします。もしここで [キャンセル] をクリックしてしまった場合は、Web ブラウザに表示されている [Open WorkSpaces application] をクリックでも同じ画面に遷移します。

数秒後に WorkSpaces クライアントアプリケーションが起動するので [Continue to sign in to WorkSpaces] をクリックします。

再び Web ブラウザに遷移し、以下のようなページが表示されるので [Log in to WorkSpaces] をクリックします。

さらに Web ブラウザ上で「workspaces を開きますか？」と訊かれるので、[workspaces を開く] をクリックします。

WorkSpaces クライアントアプリケーションに遷移するので、パスワードを入力し [Sign In] をクリックします (註：ここで入力可能なのはパスワードのみで、ユーザー名を入力/変更することは不可能になっています)。

WorkSpaces にログインできました。

余談となりますが、このスクリーンショットを取得する時が、この PC にインストールされている WorkSpaces クライアントアプリケーションで WorkSpaces にログインする初めてのログインだったため、WorkSpaces の「登録コード」は登録されていない状態でした。にもかかわらず、ログインプロセスの過程で WorkSpaces の「登録コード」の入力は求められないまま、ログインプロセスが完了しました。

試しに、WorkSpaces クライアントアプリケーションのメニューから [Settings] - [Manage Login Information...] を開いたところ、「登録コード」が自動的に登録されていることが確認できました。これは地味だけど便利です。

カスタム URI を使って「ユーザー名」と「登録コード」を指定した場合に似ていますね。

ログインが確認できたので、WorkSpaces からサインアウトして、Okta からも Sign Out します。

WorkSpaces クライアントアプリケーションからログイン

今度は、WorkSpaces クライアントアプリケーションからログインプロセスを開始してみます。 [Okta からログイン] の手順に続けて行っているので、WorkSpaces の「登録コード」は登録済みの状態で行っています。

最初に WorkSpaces クライアントアプリケーションを起動します。すると、いつもであればユーザー名とパスワードの入力を求められるハズが、[Continue to sign in to WorkSpaces] のクリックを求められるだけの画面になっているのでクリックします。

Web ブラウザが起動し、WorkSpaces SAML アプリケーションにアクセスするために Okta へのサインインを求められるので、[email protected] でサインインします。

Web ブラウザで、先ほど見たのと同じ画面が表示されるので [Log in to WorkSpaces] をクリックします。

そして、Web ブラウザで、こちらも先ほどと同じ画面が表示されるので [workspaces を開く] をクリックします。

すると、WorkSpaces クライアントアプリケーションに遷移するので、パスワードを入力し [Sign In] をクリックします (註：ここでも入力可能なのはパスワードのみで、ユーザー名を入力/変更することは不可能になっています)。

WorkSpaces にログインできました。

ちなみに WorkSpaces クライアントアプリケーションのメニューから [Settings] - [Manage Login Information...] を開き、「登録コード」手動で削除し、WorkSpaces クライアントアプリケーションを再起動したところ、WorkSpaces の「登録コード」の入力を求められたので、WorkSpaces クライアントアプリケーションからログインプロセスを開始する場合には、初回起動時に各利用者が「登録コード」を登録するか、カスタム URI 等を使用する必要がありそうです。

また、細かい話になりますが、WorkSpaces へのログインを Okta から行うか WorkSpaces クライアントアプリケーションから行うかにかかわらず、WorkSpaces へのログインプロセス中に、サインイン済みの AWS マネジメントコンソールから強制的にサインアウトされますので、ご承知おきください。

おわりに

だいぶ長くなりましたが、WorkSpaces の SAML 統合を使用した際の、WorkSpaces へのログインプロセスがどう変わるのかを確認してみました。 Web ブラウザと WorkSpaces クライアントアプリケーション間を行ったり来たりするのが面白いですね。実際の運用環境で、ボタンをクリックする回数を減らしたい場合は、Web ブラウザ側で "workspaces.xxxxxxxx.amazon.com でこのタイプのリンクは常に関連付けられたアプリで開く" のチェックを入れておくと良さそうです。

実は、今回実際に試してみるまで、WorkSpaces クライアントアプリケーションではパスワードの入力すら求められることなく WorkSpaces へのログインが完了するのだろう、と勝手に勘違いしていました。なので、パスワードの入力を求められた時には、どこかで設定を誤ったのか？あるいは何か設定が足りないのか？と何度もチェックしてしまいました。

最終的には、以下の AWS 公式ドキュメントを確認し、パスワードの入力なしにログインするには、証明書ベースの認証 (CBA) が必要だということが分かり、一人で勝手に焦って一人で勝手に安心していた、というのは内緒です。